The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
In conventional database systems, users access their data resources in one logical database. A user of such a conventional system typically retrieves data from and stores data on the system using the user's own systems. A user system might remotely access one of a plurality of server systems that might in turn access the database system. Data retrieval from the system might include the issuance of a query from the user system to the database system. The database system might process the request for information received in the query and send to the user system information relevant to the request.
During this process, data may be transformed through various formats and protocols in the various tiers of the system: from Extensible Markup Language (XML) or Hypertext Markup Language (HTML) text to JAVA® Objects to relational data structures and back again. In particular the latter transition is known in the industry as the O/R (object/relational) boundary and is the subject of a great amount of developer effort and 3rd party development tool support. Transitions across the object-to-relational data structure boundary can be difficult because the representation one uses typically in a procedural language like the JAVA® programming language, for a complex object, is typically quite different from the optimal manner in which that data is stored and indexed in a relational database, which is the dominant location for enterprise data of this sort.
A user of a relational database management systems (RDBMS) can implement a user interface (UI) using 3rd party programming tools, which automate transactions across the O/R boundary. These programming tools can include a programming language, such as Apex Code by salesforce.com of San Francisco, Calif., which is integrated with configurations or configured behaviors to help users graphically configure how their systems operate. These tools can be used effectively in on-demand and/or multi-tenant database systems.
Such tools allow fields in some objects to be automatically dependent upon other fields in other objects. For example, a summation field of a container object sums the values of fields of other objects. Some field values are automatically enforced based on other field values. An administrator may set the enforcement code. For example, it may not make sense to have a sales opportunity in which the forecast category is “committed” when it is still in the “negotiation” stage. If the opportunity is entered this way, then the administrator's rules can change the forecast category to one which makes sense, such as “not committed.”
The tools also allow for users to program custom code or set configurations. The custom code may incorporate dependencies, such that the field of one object depends upon a value of a field in another object.
Sometimes, a user's custom code may execute before a dependency has been updated. This can cause problems in that the wrong data or an unknown state can be introduced into the system. The end result is that a seemingly straightforward change can corrupt otherwise useful data in the database.